Add isNotNull/hasDefault to CleanField and relationFieldMap alias support

Summary

Two safe, additive enhancements to graphql-codegen, back-ported from Dashboard's dynamic codegen system (ref: constructive-planning#651):

1. isNotNull / hasDefault metadata on CleanField — infer-tables.ts now populates two optional boolean fields on every CleanField:

• isNotNull: derived from the NON_NULL wrapper on the entity's introspection field type
• hasDefault: inferred by comparing entity field nullability against CreateXxxInput field nullability — if a field is NOT NULL on the entity but not required in the create input, it likely has a server-side default (serial, uuid_generate_v4(), now(), etc.)

2. relationFieldMap + GraphQL alias support — QueryOptions gains an optional relationFieldMap: Record<string, string | null> that maps consumer-facing field names to actual schema field names. When the names differ, a GraphQL alias is emitted (contact: contactByOwnerId { … }). Mapping to null omits the field entirely. This is wired through buildSelect → generateSelectQueryAST → generateFieldSelectionsFromOptions via two new helpers: resolveSelectionFieldName() and createFieldSelectionNode().

Both features are purely additive — all new fields/parameters are optional, existing behavior is unchanged, all 301 tests pass.

Review & Testing Checklist for Human

• Verify hasDefault inference logic against a real schema: The heuristic in buildCreateInputRequiredFieldSet assumes Create${Entity}Input wraps ${Entity}Input — confirm this holds for your PostGraphile schemas (especially with custom inflection via InflektPreset). Fields that are NOT NULL on the entity but absent from EntityInput (computed columns) will get hasDefault = true, which may or may not be the desired semantics.
• Validate alias AST output: createFieldSelectionNode manually spreads the FieldNode and attaches an alias: { kind: Kind.NAME, value } override. Confirm the resulting AST produces valid GraphQL when printed (e.g., contact: contactByOwnerId { id name }).
• Test relationFieldMap omission: Pass { someField: null } and verify the field is correctly omitted from the generated query.
• Consider whether buildFindOne/buildCount need relationFieldMap: Currently only wired through buildSelect. If find-one or count queries need relation aliasing, this will need expansion.

Notes

• Related issue: https://github.com/constructive-io/constructive-planning/issues/651
• Link to Devin run: https://app.devin.ai/sessions/cc15c94da78646f28f931048c542c26f
• Requested by: @pyramation